Users who register custom toolchain families (e.g. gated behind a
string_flag like "custom" vs "prebuilt") have no way to prevent the
default-registered toolchains from acting as a silent fallback. When a
user requests a custom toolchain at a version they didn't register,
Bazel's toolchain resolution quietly falls back to the default prebuilt
toolchain instead of producing an error.

This adds a `toolchain_target_settings` attribute to `python.override`
that appends the given `config_setting` labels to the `target_settings`
of every toolchain registered by the module extension:

```starlark
python.override(
    toolchain_target_settings = ["@@//:python_toolchain_family_prebuilt"],
)
```

These settings are appended to the `target_settings` of all toolchains
registered by the extension, including any that already have settings
from `python.single_version_platform_override`. Toolchains registered
outside the extension (e.g. via `local_runtime_toolchains_repo`) are not
affected.

Note: `toolchain_target_settings` is popped from the config `default`
dict before it reaches `python_register_toolchains()`, so it doesn't
leak into the `python_repository` kwargs.

Integration test passes across the full Bazel version matrix (7.7.0,
8.5.1, 9.0.0rc1). Verified the test fails without the fix (default
toolchain silently resolves as fallback).

Fixes #3673

---------

Co-authored-by: Richard Levasseur <rlevasseur@google.com>